1. Field of the Present Invention
The present invention is in the field of networked data processing systems and more particularly systems having multiple execution environments.
2. History of Related Art
In the field of networked computing, the Java® programming language developed by Sun Microsystems is well known. Java® applications are designed to be platform independent, meaning that they will function properly on any Java® enabled system, regardless of the underlying hardware or operating system software. Platform independence is achieved by installing or otherwise provisioning a data processing system with a Java® runtime environment (JRE). A JRE includes all the software needed to interpret or execute Java® code. Typically a Java® source program is compiled to create one or more Java® “class” files. The class file is comprised of architecture neutral byte codes. The byte codes in a class file are interpreted by a Java® virtual machine (JVM) that comprises a portion of the JRE. The JRE effectively insulates the Java® application from the system's operating system and software.
JREs are developed and distributed by a variety of vendors and are typically distributed without charge or at a de minims charge. Java® applications are prevalent in virtually all networked environments including the Internet and wireless communication networks. As a result, most systems that do any significant amount of networked processing have at least one installed version of a JRE.
All JREs are not, however, the same. JREs come in different revisions and versions and from different sources. Java® applications are typically developed using a particular JRE (the development JRE). When the compiled application is installed and executed either locally or via a network, the JRE on the user's system that will be used to execute the application may not be compatible with the development JRE. If the two JREs have significant or sometimes even minor incompatibilities, improper functioning of the application may result. Moreover, the local system may have multiple JREs within its file system. For a person not skilled in the Java®-based computing, being aware of JRE incompatibility issues and taking appropriate action to obviate them can be difficult, tedious, or even beyond the person's ability. Accordingly, it would be desirable to implement a data processing network, mechanism, and method for determining which if any execution environment is appropriate for a particular application.
Turning now to the drawings, FIG. 1 illustrates selected elements of a data processing system 100. In the depicted embodiment, the software elements of system 100 include an operating system 102, a set of Java® runtime environments 104-1 through 104-3 (generically or collectively referred to herein as JRE(s) 104), and a set of applications 106-1 through 106-3 (generically or collectively referred to herein as application(s) 106). Hardware elements (not depicted) of system 100 include a microprocessor having access to a system memory or some other form of storage and an I/O device such as a display screen, keyboard, keypad, pointing device, and the like as will be familiar to those knowledgeable in data processing system design. System 100 may be implemented as a conventional multiprocessor server, a conventional desktop or notebook personal computer, a network computer, or any number of network devices including cell phones, handheld or pocket PCs, personal digital assistants (PDAs), and so forth.
As depicted in greater detail in FIG. 2, each JRE 104 includes the elements needed to execute a Java® application on a data processing system. These elements include a Java® virtual machine (JVM) 110, Java® API's 120, user interface toolkits 130, and deployment agents including Java® Web Start agent 140 and Java® Plug-in 150, all of which are standard JRE elements available from multiple sources including Sun Microsystems. JVM 110 enables platform independence of Java® code and Java® application by interpreting compiled Java® objects (class files) for the operating system 100. JVM 110 insulates application programs from the underlying platform (operating system and hardware) by converting the platform independent byte codes or class files to native code. The API's 120 provide interfaces needed to build and execute Java® applications and applets (Java® applications that execute within a browser framework). Toolkits 130 provide user interaction extensions to the developer. Web Start agent 140 provides a mechanism for executing network-distributed applications outside the confines of a web browser. Java® Plug-in 145 enables a browser to invoke a locally installed JVM to handle a Java® applet.
As shown in FIG. 1, it is not uncommon to encounter systems on which two or more JREs are installed. In some cases, developers and users have intentionally installed various JRE versions. In other cases, JREs may be installed automatically such as when the users install other application products. Regardless of how the plurality of JREs were installed, the presence of more than one JRE can lead to unintended results when applications are executed locally or via a network. In some cases, different JREs are simply incompatible with each other. In other cases, JREs developed by different vendors may have subtle execution differences. These incompatibility issues are especially noticeable when the JREs include vendor specific Java® extensions. In any event, it is generally desirable to execute an application within the same environment in which the application was developed or, at least, in an environment that is highly compatible.
When a JRE or an application that contains a JRE is installed, the system's “PATH” environment variable is often modified to add directories pointing to the JRE and other needed executable commands in a manner that varies among different applications and vendors. The PATH variable is often used to search for executables when a program is launched. If the proper command is not found, the program cannot be executed. In a conventional Java® implementation, for a system with multiple JREs, the user may need to specify the JRE path either through the command line in the case of a standalone Java application or through a Web Start Application Manager panel in the case of a networked Java application. In the case of standalone application, failure to properly specify the correct JRE path explicitly will prompt the application to search for a JRE from the directories specified in the PATH variable. The application will execute within the first JRE that it finds as it proceeds through the directories specified in the PATH variable. If the first-found JRE is incompatible, the application will fail to execute as intended even though a compatible JRE may exist in another PATH directory (i.e., a path directory that has not been searched yet). In the case of the network application invoked via Web Start, the Web Start will try to automatically download the appropriate JRE from the vendor's web site to the system if the desired JRE is not specified. Casual users of Java® may find it difficult to determine an appropriate JRE on a system having multiple JREs. The present invention, as set forth below, addresses these drawbacks of conventional Java® implementations by describing a system and method that select the most appropriate JRE for any given application without user interaction.